%************************************************
\myChapter{Requirements and Software Architecture}\label{ch:design}

\section{Functional requirements}
Functional requirements describe \textit{what} the system should do, without focusing on \textit{how} it will be realized. The Visual Workflow Editor, will be a \ac{GUI}, thus the functional requirements match with the user requirements. The user should be able of:
\begin{itemize}
	\item Create a Diagram representing a workflow
	\item Set the diagram properties, in particular way the details about the OGSA-DAI service
	\item Add an Activity to the workflow using a palette and a panel to place the elements.
	\item Set the activity properties, selecting the possible values from list retrieved from the OGSA-DAI service. 
	\item Add inputs and outputs to an activity
	\item Link to activity together, using a graphical tool that allows to select the source and destination of the connection
	\item Save/Load a workflow diagram
	\item Validate the correctness of a workflow
	\item Deploy a workflow to an OGSA-DAI service
	\item Receive the result of execution from the OGSA-DAI service		
\end{itemize}

\begin{figure}[htb]
    \centering
    \includegraphics[scale=0.5]{gfx/highlevel_sequence}
    \caption{High level sequence diagram}\label{fig:highlevel_sequence}
\end{figure}

Figure~\ref{fig:highlevel_sequence} shows a sequence diagram, with some high level actions driven by the user.
\section{Non-functional requirements}
Non-functional requirements cover general design guidelines and system constraints that can be stated during the definitions of the requirements. Those are the non-functional requirements of the Visual Workflow Editor:
\begin{itemize}	
	\item it should be user friendly, and give the possibility to build a workflow using graphical elements such a palette of tools and a panel to compose them. Well know mechanisms, like drag-and-drop, palette tool and copy paste, should be available to the user.
 	\item it must be operating system independent, and portable without additional development. 
	\item it must be easily extendible, in terms of design using an object oriented paradigm, and in terms of third part extension by mean of plugins
	\item it must be modular, using a Model View Control patter to interconnect each module, and giving the possibility to be reused and integrated in other products	
	\item the user generated diagram must be transformed in a valid document based workflows that can be submitted to OGSA-DAI service
\end{itemize}

\section{Software Architecture}
The requirements that have been identified for the project, describe a problem that involves different elements of the system, from the UI interacting with the user, to the business logic that communicates with the OGSA-DAI service. To have better understanding of the problem, and organise in an effective way the implementation of the project, is worth to define the \textit{Software Architecture}. In \cite{bass2003sap} the architecture of a software is defined as:
\begin{quote}
	The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
\end{quote}
According to the definition an architecture defines elements and gives information how them relate to each other. Thus, an architecture is an abstraction that gives an high level view of the problem, skipping details that do not effect how they use or are used by or interact with other elements.

The project has been partitioned in four implementation units (called module or package), with specific behaviour and responsibilities:
\begin{itemize}
	\item Resource and Activity Discovery (RAD)
	\item Visual Workflow Representation (VWR)
	\item Diagram Serialization and Validation (DSV)
	\item Workflow Execution (WE)
\end{itemize}

\subsection{Resource and Activity Discovery}
As explained in \ref{sec:ogsadai_workflow}, the central unit of an OGSA-DAI workflow are activities, that are strictly coupled with OGSA-DAI resources. This module is in charge of interacting with the OGSA-DAI service, fetching informations about the resources and the activities that are deployed on it. In terms of the functionalities offered to the other system modules, it can be considered as belonging to the business logic layer; in terms of technology it can be considered as client that uses the \ac{CTW} to exchange messages with the OGSA-DAI service.

\subsection{Visual Workflow Representation}
This module is the central package of the project, and for its importance the methodology and technology used to design it are explained in the chapter\ref{ch:methodology}. From an abstract and high level point of view, the module manage the graphical representation and composition of an OGSA-DAI workflow. This element of the architecture is in charge of the UI, and uses the functionalities exposed by others modules to obtain data from the OGSA-DAI server, accomplish to load/save operation and execute the workflow.

\subsection{Diagram Serialization and Validation}
One of the  non-user requirements, is that from the diagram must be possible to produce a valid xml file, according to the definition of OGSA-DAI workflow. The Diagram Serialization is in charge of transforming the diagram produced by central module, in a format that can be ``executed''. The Validation feature is in charge of checking if the produced file, is a valid OGSA-DAI, checking it against a set of constraints. This module might be considered as a subsection of the Visual Workflow Representation, but at this stage it's important to remark that the VWR is dealing with ``graphical'' representation of the workflow, meanwhile DSV deals with a low level representation.

\subsection{Workflow Execution}
This module is in charge of submitting a document description to the OGSA-DAI service in  order to execute the workflow it self. This module has to deal with all the features that are related to the execution such as execution status report and execution monitoring. 

\subsection{Module interaction}
In the Figure~\ref{fig:system_architecture} is represented the system architecture, and the interaction between each module. Is important to underline that core module (VWR) access OGSA-DAI only through other modules. This solution adds a level of abstraction, and makes the Visual Workflow Representation more general.

\begin{figure}[htb]
    \centering
    \includegraphics[scale=0.5]{gfx/system_architecture}
    \caption{System architecture representation and interaction}\label{fig:system_architecture}
\end{figure}


. 